I have several concerns regarding this pull request:

Firstly, I'm not sure that the centralized cmd_requires_privileges() function is the best choice. I'd prefer to delegate the decision of whether elevated privileges are required to the commands themselves, perhaps by adding a bool Command::privileges_required() method. For example, imagine a third-party dnf5 plugin implementing a new command that does not run a transaction but requires administrator privileges for some reason. How can this be handled with the current design? The plugin could be completely private to a customer, and dnf5 would not know anything about it, not even its name, to handle it in the centralized function.

Secondly, I don't think that having read/write access to <install root>/run/dnf/rpmtransaction.lock is sufficient to determine if a user has the necessary privileges to run the transaction. Consider the example mentioned in this comment #849 (comment). Although the user has full control over the specified install root, they still cannot run the RPM transaction successfully due to a failed chown() call.

Hi Marek,

I'd prefer to delegate the decision of whether elevated privileges are required to the commands themselves, perhaps by adding a bool Command::privileges_required() method

Yeah, I was also thinking about this approach. Just this would require changing each command and making this a prerequisite when implementing a new one. This PR is a simple approach to the things.

For example, imagine a third-party dnf5 plugin implementing a new command that does not run a transaction but requires administrator privileges for some reason

I was focused just on the core commands and plugins here. The 3rd party plugins could handle the situation in their way. Anyway, the current PR is really just trying to setup a single place where the initial check of privileges happens. If user doesn't have privileges for the operation, it would be denied anyway even without this PR.

Secondly, I don't think that having read/write access to /run/dnf/rpmtransaction.lock is sufficient to determine if a user has the necessary privileges to run the transaction

Yes, it is not sufficient for this use case. This specific scenario could be handled later e.g. by the install command itself. The idea here is to handle the majority of common use cases by giving the user a unified message. In other cases, operation would fail as it was before...

Thanks for clarification! Let's go with this simple approach than.